Merge Development to Main to close Issues #119

stratofax · 2022-09-22T14:42:17Z

This version (0.1.3) of BallotMaker generates ballots with hidden widgets, thus completing the work for Milestone 2. Generate ballot PDFs with embedded form objects. This merge to main will close the associated issues and milestones.

Closes BallotLab milestone #2

BallotStyles don't drive the contests.

Fixes BallotLab #82.

Fixes BallotLab #83.

Fixes BallotLab #86.

Fixes BallotLab #84.

Updates #84.

Fixes BallotLab #85. This isn't quite right: fails if a slate has candidates from different parties. Deferring on that case for now.

Mark write-in status as boolean (matching the contents of the EDF). No issue attached.

The error was introduced in the process of folding write-ins into contests. - Remove convoluted extra step that makes it harder to do this correctly. - Candidate names are grouped in arrays. Now do the same for parties. - Use 'is_write_in' for the write-in boolean field.

Handles case where candidates in a slate have different parties.

…entical.

…ssing.

Fixes BallotLab #86.

@id

Significant update of contests: - Include '@id's of ballot measure contests (candidates already happening). - Include '@id's of candidate and ballot measure contest selections. - Updates and bug fixes for write-ins in candidate contests. - Multi-candidate slates: - Combine names of candidates into list. Names are stored in lists even when there is only one candidate. - Combine parties of candidate IFF they are the same. Parties are always stored in lists, and empty if there is no party.

Only updates the JSON file not the custom data file. See: https://github.com/trustthevote-project/nist-1500-100-103-examples/test_cases/september_test_case.json

- Candidate parties are now a list. - 'write_in' -> 'is_write_in'

These are NOT intended to follow any standard, merely to aid in debugging. There's an ongoing conversation about the format of human readable IDs.

Extraction code validates and generates ballots, passes GitHub Actions testing, but pytest still fails locally. Good enough for a merge.

* Update version to 0.1.3 upon milestone completion * Update CHANGELOG.md Co-authored-by: Ion Y <[email protected]> * Update CHANGELOG.md Co-authored-by: Ion Y <[email protected]> * Update CHANGELOG.md Co-authored-by: Ion Y <[email protected]> * Use short dash in header * Remove unneeded files Co-authored-by: Ion Y <[email protected]>

ion-oset · 2022-09-22T23:04:38Z

Checklist to finish before hitting merge.

Version updated in:
- pyproject.toml
- CHANGELOG.md
~~Tag development branch as version (v0.1.3).~~
Close all remaining milestone issues, or ~~remove them from the milestone~~ link them to this PR.

After the merge is successful and tests all pass

Tag main branch as version (v0.1.3).

EDIT: As discussed on the call: the tag should be on main after the merge.

Notes:

This should be a regular merge not a rebase merge.
We should come up with standard message for closing milestones. Something like:
```
Closes BallotLab milestone #2: https://github.com/TrustTheVote-Project/BallotLab/milestone/2
```
- In this case it closes milestone For multi-column contests, add a "continued" column header #1 also, so it might be two lines.

stratofax · 2022-09-23T01:56:13Z

@ion-oset, handy and useful checklist, worth preserving on DevComm.

I believe the Issues associated with this PR will close automatically when the PR is merged. Does this address the last item in the checklist above?

Close all remaining milestone issues, or remove them from the milestone.

ion-oset · 2022-09-23T18:25:37Z

Some how I missed the linked issues - yes that would address closing them! I've updated the check list.

I've unchecked Tag development branch as version (v0.1.3) though. I don't see any tags on the upstream repository

stratofax · 2022-09-23T20:00:08Z

The tags exist on my local copy of the repo on the development branch.

[I] neil@Neils-Mac-mini:~/r/t/BallotLab|development✓
➤ git tag --list
v0.1.2
v0.1.3

stratofax · 2022-09-26T21:58:26Z

I think I should delete the development branch, having reached this milestone. We can then create new branches for the next milestone. Thoughts?

stratofax · 2022-09-26T22:06:31Z

Tagged with lightweight tag v0.1.3: Tags · TrustTheVote-Project/BallotLab

ion-oset · 2022-09-27T00:27:34Z

I think I should delete the development branch, having reached this milestone. We can then create new branches for the next milestone. Thoughts?

Move development to be on what is now main.

     git branch -f main development

The next milestone starts from there, and new branches are based on development, not on main.

The purpose of a development branch is as the place to combine all accepted branches that are part of a milestone. When they are stable and ready they merge into the stable branch (main).

stratofax · 2022-09-27T15:58:30Z

I agree with the premise of the development branch, I'm proposing one option to implement this -- instead of having a long running development branch, create branches for each milestone, merge them onto main when the milestone is completed, delete the milestone branch, rinse, repeat.

You're proposing another option -- maintain the development branch as a persistent target for work around a specific milestone. When we complete a milestone, use the git branch --force command to ensure that the development branch is at exactly the same point as main.

Note: I checked the git documentation and it seems like the way to do what you describe,

Move development to be on what is now main

would look like this:

     git branch -f development main

where the branchname is development and the start-point is main

Here's the git documentation command template:

git branch [-f] <branchname> [<start-point>]

So, this post is my attempt to make sure I understand your implementation strategy, as well as mine.

Both strategies share essential features:

there's a primary development branch where all the work for a milestone lands before it's merged to main
When we reach a milestone and merge to main we ensure that the development branch and main are identical.

The difference is (as far as I can tell) exactly how we ensure that main and the milestone development branch are identical immedately after merging. You suggest using a git command on a long-lived development branch; I suggest creating a new branch off of main for the upcoming milestone.

Let's discuss this at today's meeting.

ion-oset · 2022-09-27T16:39:24Z

Note: I checked the git documentation and it seems like the way to do what you describe,

Move development to be on what is now main

would look like this:
git branch -f development main 
where the branch name is development and the start-point is main

You are correct. I want to note that I typed that wrong even after I looked it up and noted that it was the way it was. It's the reverse of nearly every other branch option, where the target branch name comes at the end. Git is is many things but consistent is not one of them.

ion-oset · 2022-09-27T17:04:32Z

So, this post is my attempt to make sure I understand your implementation strategy, as well as mine.

I've moved this to the branching and merging strategy discussion so whatever we decide doesn't get lost on a closed PR thread.

ion-oset added 30 commits August 20, 2022 18:46

Script to convert NIST EDF data into BallotLab data.

f38ced9

First pass at candidate contests.

88aa5bc

Ordered content includes headers; use argparse.

41e188c

Flags for keeping write-ins, n-of-m contests.

25ff3cf

Drop 'keep' flags, add '--debug' for exceptions, more doc comments.

584bb41

Significant refactoring of candidate contests.

43eb184

BallotStyles don't drive the contests.

Add offices and parties to candidate contests.

24b921f

Add ballot measure contests.

9f0ab55

Add ballot text; don't return offices or parties for candidates.

f1fd991

Add README for ballot-lab-data script.

309db0e

Add party names to candidates.

f5090b8

Add votes allowed on candidates races (even if it's the default).

55b5b38

Fixes BallotLab #82.

Add party abbreviations to candidates.

a262592

Fixes BallotLab #83.

Include '@id's with contests.

4a27316

Fixes BallotLab #86.

Use 'ContestSelectionId's instead of a count for write-ins.

15efb15

Fixes BallotLab #84.

Add selection IDs to all candidates, not just write-ins.

4355de7

Updates #84.

Properly set up multi-candidate slates/tickets.

26deeaf

Fixes BallotLab #85. This isn't quite right: fails if a slate has candidates from different parties. Deferring on that case for now.

Merge write-ins into candidte contests.

fb03e3f

Mark write-in status as boolean (matching the contents of the EDF). No issue attached.

Multi-candidate slates: Use party IDs to collapse identical parties.

78f933a

Handles case where candidates in a slate have different parties.

Multi-candidate slates: Only collapse party IDs if ALL parties are id…

e658646

…entical.

Drop null fields of parties; use an empty dictionary if a party is mi…

d48ddf7

…ssing.

Add IDs to ballot measures contests.

4d1bfb4

Add IDs to ballot measure contest selections.

8fd9337

Fixes BallotLab #86.

Update README for 'ballot-lab-data' script.

6a88c50

Update Spacetown data to match generator updates.

fb195a0

Use September test case for Spacetown data.

fe81fbc

Only updates the JSON file not the custom data file. See: https://github.com/trustthevote-project/nist-1500-100-103-examples/test_cases/september_test_case.json

Update the internal Spacetown data to use the September test case.

818f21b

- Candidate parties are now a list. - 'write_in' -> 'is_write_in'

Switch to human readable IDs.

9b91232

These are NOT intended to follow any standard, merely to aid in debugging. There's an ongoing conversation about the format of human readable IDs.

stratofax and others added 7 commits September 16, 2022 21:29

Update CLI to run demo

52da16e

First round of code cleanup

13da497

Code cleanup and comments

12a2380

Hide widgets, remove unused data class

5a3a03e

Add TODOs and backlinks

12196c1

Merge pull request #113 from stratofax/development

b2c7092

Extraction code validates and generates ballots, passes GitHub Actions testing, but pytest still fails locally. Good enough for a merge.

stratofax requested a review from ion-oset September 22, 2022 14:42

stratofax self-assigned this Sep 22, 2022

stratofax added the enhancement New feature or request label Sep 22, 2022

Remove test output PDF from repo root

45f06ba

stratofax added this to the 2. Generate ballot PDFs with embedded form objects milestone Sep 22, 2022

stratofax merged commit 9b34c45 into main Sep 26, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge Development to Main to close Issues #119

Merge Development to Main to close Issues #119

stratofax commented Sep 22, 2022 •

edited

Loading

ion-oset commented Sep 22, 2022 •

edited by stratofax

Loading

stratofax commented Sep 23, 2022

ion-oset commented Sep 23, 2022 •

edited

Loading

stratofax commented Sep 23, 2022

stratofax commented Sep 26, 2022

stratofax commented Sep 26, 2022

ion-oset commented Sep 27, 2022

stratofax commented Sep 27, 2022

ion-oset commented Sep 27, 2022 •

edited

Loading

ion-oset commented Sep 27, 2022 •

edited

Loading

Merge Development to Main to close Issues #119

Merge Development to Main to close Issues #119

Conversation

stratofax commented Sep 22, 2022 • edited Loading

ion-oset commented Sep 22, 2022 • edited by stratofax Loading

stratofax commented Sep 23, 2022

ion-oset commented Sep 23, 2022 • edited Loading

stratofax commented Sep 23, 2022

stratofax commented Sep 26, 2022

stratofax commented Sep 26, 2022

ion-oset commented Sep 27, 2022

stratofax commented Sep 27, 2022

ion-oset commented Sep 27, 2022 • edited Loading

ion-oset commented Sep 27, 2022 • edited Loading

stratofax commented Sep 22, 2022 •

edited

Loading

ion-oset commented Sep 22, 2022 •

edited by stratofax

Loading

ion-oset commented Sep 23, 2022 •

edited

Loading

ion-oset commented Sep 27, 2022 •

edited

Loading

ion-oset commented Sep 27, 2022 •

edited

Loading